Diversified business forms through activation of collaboration across companies and departments in recent years are accompanied by rapidly increasing needs for communication between terminals connected to different corporate LANs or department LANs. More specifically, the needs for communication between terminals connected to different private networks have been increasing. Due to this background, a method of communicating between terminals connected to different private networks has been proposed in recent years.
The communication between the terminals connected to the different private networks is realized by communicating through a relay server provided in a global network. However, the private networks are generally provided with firewalls. Therefore, the communication between the terminals connected to the different private networks is blocked off by the firewalls in many cases.
Generally, the firewall is set to allow a specific TCP (Transmission Control Protocol) communication from the private network to the global network. Here, as the TCP communication used for web browsing communication, there are TCP communication with the destination port of 80, i.e., HTTP (Hypertext Transfer Protocol) communication, and TCP communication with the destination port of 443, i.e., HTTPS (Hypertext Transfer Protocol Layer Security) communication. A TCP connection is initially established from one terminal on a private network to the relay server, to allow two-directional communication between the terminal and the relay server. Then, the terminal transmits a transmission data for a desired transmission destination terminal to the relay server by using the established TCP connection. The relay server transmits the received data onto a TCP connection established for the destination terminal.
As described above, in order to realize the communication between the different private networks, the relay server needs to ensure communication security between the terminals and the relay server. Since the relay server is provided on the global network, communication between the terminals is supposed to pass through the global network. The global network is always exposed to a security risk such as eavesdropping, unlike the private network, and accordingly, communication between the terminal and the relay server needs to be enciphered.
There are mainly known two different techniques to realize communication cipher between the terminal and the relay server. In a first technique, an HTTPS session is established between the terminal and the relay server, in which communication between the terminal and the relay server is carried out on the HTTP session to encipher the communication. More specifically, a shared key is first transferred between the terminal and relay server by SSL (Security Socket Layer) by using the TCP connection established between them. Data to be transmitted to a destination is enciphered in the terminal by use of the shared key transferred from the relay server. The relay server deciphers the enciphered data by use of the shared key, and re-enciphers the deciphered data by use of another shared key transferred when the HTTPS session with a destination terminal is established, to transmit the re-enciphered data to the destination terminal. Such an example of the first technique is SoftEther.
The relay server in the first technique determines the destination terminal based on a destination data described in the transmission data from the transmission source terminal. It should be noted that since the transmission data from the source terminal is enciphered in any way, the relay server needs to decipher the transmission data in order to refer to the destination data of the transmission data and further re-encipher it. In SoftEther, the source terminal encapsulates the transmission data by use of HTTPS in a packet form including layer-2 header information. Then, the source terminal transmits the encapsulated data by use of an HTTPS connection established to the relay server in advance. At this time, the relay server decapsulates the encapsulated data. Since the transmission data has been encapsulated by use of HTTPS, a decapsulating process includes a process of deciphering the enciphered data. Next, the relay server refers to the data extracted through the decapsulation, i.e., the layer-2 header of the packet including the layer-2 header information, and determines the destination terminal from a destination MAC address. After the determination, the relay server encapsulates the extracted data again (i.e., re-enciphers the deciphered data) by use of HTTPS, and transmits the packet including the extracted data to the destination terminal by using a HTTPS connection.
In a second technique, a HTTPS session is directly established between terminals to communicate with each other by use of TCP connection established between each of the terminals and the relay server. The terminal first establishes a TCP connection having the destination port of 443 with the relay server. Then, the TCP connection is used to exchange a shared key with the destination terminal by using SSL. Even when receiving a shared key exchanging message of SSL from the source terminal, the relay server simply transfers the received message to the destination terminal by use of the TCP connection without checking its contents. The terminal enciphers the data to be transmitted by using the shared key exchanged with the with the communication destination, and transmits the enciphered data by using the TCP connections established with the relay server. The relay server does not decrypt or re-encrypt the received data which is transmitted to the TCP connection established with the communication destination without any change. Such an example of the second related technique is described in Japanese Laid Open Patent Application (JP-P2006-50191A). An operation of such a relay server is similar to operation of a Web Proxy server that has been frequently used in the related technique.
The relay server according to the second related technique determines a transfer destination terminal of a received data in connection base on the basis of information in which a TCP connection established between the terminals and the relay server corresponds to a communication destination terminal. Such an example of the second related technique is described in Japanese Laid Open Patent Applications (JP-P2006-50191A and JP-P2003-32236A), and Japanese Patent No. 3637863.
The difference between the first related technique and the second related technique is in that the relay server according to the second related technique only terminates the TCP connection without terminating HTTPS sessions (i.e. without deciphering and enciphering communication between the terminals), as opposed to the relay server according to the first related technique which terminates HTTPS sessions (i.e. decipherment and encipherment communication between the terminals).
The first related technique has a problem that the received data needs to be deciphered and re-enciphered in data transfer by the relay server, and deciphering/enciphering processes load is applied for every transfer.
The relay server according to the second related technique has a process load less than that of the first related technique because the encipherment and deciphering processes are omitted. However, there is a problem that communication via the relay server is not available from a private network terminal provided with highly functional firewalls which carries out a filtering operation by examining its contents in a layer 5 or higher of transfer data. When the highly functional firewall is provided in the private network, communication from the terminal to the relay server is not blocked off until establishing the TCP connection of the destination port of 443, but there is a possibility that the firewall blocks off an SSL message for exchanging the shared key transferred from the relay server to the terminal.
The problem of the second related technique will be described below. An SSL message includes a field called an SSL record header in which a message type is written. The message type includes handshake, change cipher spec, and application data or the like, and handshake and change cipher spec are written as the message type of messages for exchanging the shared keys. The SSL record header itself is not usually enciphered, and its contents can be examined by the firewall. That is, the firewall can check the message type of the SSL record header and a message transmission direction and detect a direction of the SSL sessions. Therefore, it is detected by the firewall that the SSL session is extended from the relay server in the global network to the terminal in the private network, according to the second related technique. The above SSL message is blocked off because the firewall is generally operated under the policies to block off establishment of connections and sessions from the global network to the private networks.